The present invention relates to network server security in general and in particular to web application security scanning in the case of infinite scan sites.
There are a number of different configurations of network client-server interfaces available today, but the most common network in use is the Internet, a global internetwork of networks and networks that use Internet protocols and/or interfaces, such as extranets, intranets, local services, and other variations. In the general case, to which inventions described herein apply, clients connect to servers over the network and clients are not always trusted computers. As a result, the designers of the servers need to ensure that untrusted clients cannot perform malicious acts or access unauthorized portions of the server through the network.
One approach to ensure that servers cannot be accessed in an unauthorized manner is to only provide access to secured and trusted clients. However, in many situations, that is not possible. For example, if a merchant was running an on-line store, the merchant would want to allow most anyone who has a computer to access the servers providing the on-line store functionality, but do so in a way that still prevents unauthorized interactions with the servers.
Server security is more than just requiring a username and password from each client before responding to client requests, since even a logged in user might try for unauthorized access and a typical service provided by a server might include content and functionality for use by unauthenticated and unlogged-in clients. One approach to server security is to review all of the code that runs on the server and verify that it does not include statements that allow for unauthorized activity and review all the files present on the server and their respective permissions, side-effects, etc. While this might be practical for a small installation, say a File Transfer Protocol (“FTP”) server that serves up predefined files to all comers, it is often not practical with complex, interactive applications that have many response modes.
One common use of servers in this environment, but not an exclusive use, is that of a web application. As used herein, “web” refers to a collection of documents/files, some of which have references, or links, to other documents/files in the collection. One example of a web is the World Wide Web (“WWW”), a collection of files served up by WWW servers (also called “web servers”) using Hypertext Transfer Protocol (“HTTP”) protocols or something similar. The “WWW” gets its name from the fact that most of these documents/files can be almost anywhere in the world and can be accessed anywhere in the world where there is Internet connectivity.
A web application is an application that runs on one or more servers and provides some functionality or service in response to client requests received over a network using web protocols (i.e., HTTP, HTTP Secure (“HTTPS”), or something similar). An example of a web application is a database interface, wherein a database runs on a database system and clients can access data in that database system by sending a request for service over the network to a web application server. The web application server receives the request for service and decides, according to how it is programmed, what to do with the request. It can ignore the request, send an error message back to the client, or trigger an operation with the database system and respond to the client's request by sending the client the results of the database operation.
In a highly specific example, suppose a client computer system is operated by a customer seeking to configure and purchase a laptop computer. The customer would direct the client computer system to access a web application server operated by a vendor of laptop computers. The client computer system might send a request to the web application server via the network requesting a home page of the vendor. The web application server might respond with a home page that includes features allowing the client to interact with content on the home page (such as by selecting from available model names, features, etc.), send a subsequent request to the server, etc.
All the while, the web application server is making decisions about what is appropriate to send and what is not appropriate to send, based on its programming. For example, if the client computer sends a request for an updated page with updated pricing for new options selected by the customer, the web application server might perform some calculations, perform some database look-ups, generate a new dynamic web page and return that web page to the client computer in response to the request. However, if the client computer sends a request to see data about what someone else ordered, or internal data from the database server, the web application should properly refuse to respond to the request.
Because web applications are so complex and may involve a potentially infinite number of pages, securing a web application and testing for security vulnerabilities, often involves an automated testing of the web application. Client-side web application testing refers to tests that are run from a client's point of view. For example, a client-side web application security scanner might have logic for logging in to a web application, applying valid and invalid requests to the web application, noting the web application's responses and evaluating those responses. For example, if the web application security scanner sends a request to the web application for ordering products where the prices have been altered and the response is “invalid order”, the web application security scanner might note that the web application is secure in that regard, but if the response is “thank you for your order”, the web application security scanner might note that the web application is not secure.
Once vulnerabilities have been identified, they can be brought to the attention of a web application designer for handling. Of course, if vulnerabilities are missed by the automated web application security scanner, those vulnerabilities might never get fixed. Also, if there are too many false positives, the web application designer might give up on the web application security scanner or miss some true positives. In addition, if the web application includes a potentially infinite number of sites that require scanning, the web application security scanner may never cease operating. Furthermore, web application security scanners need to perform their tests in reasonable amounts of time to be useful.
In view of the above, the inventions described herein provide improvements over existing approaches.